Skip to content

Sync UTS specs with 6.1.0 server-side resumability - #511

Merged
SimonWoolf merged 1 commit into
mainfrom
uts-6.1.0-server-resumability
Sep 3, 2026
Merged

Sync UTS specs with 6.1.0 server-side resumability#511
SimonWoolf merged 1 commit into
mainfrom
uts-6.1.0-server-resumability

Conversation

@SimonWoolf

@SimonWoolf SimonWoolf commented Jul 23, 2026

Copy link
Copy Markdown
Member

Spec PR #488 ("Move resumability decisions from the client to the server") updated features.md and api-docstrings.md but did not update the UTS test-spec sources or address createRecoveryKey's behaviour in SUSPENDED. This brings both in line.

features.md:

  • RTN16g2 is replaced by RTN16g3: createRecoveryKey() no longer returns Null in SUSPENDED. Since the client now retains its connectionKey and always attempts to resume (RTN14h), the connection remains recoverable while suspended. (RTN16g2 as written still listed SUSPENDED, which contradicts RTN8d/RTN9d retaining the key.)

UTS sources:

  • connection_id_key: RTN8c/RTN9c "id/key null in SUSPENDED" -> RTN8d/RTN9d "id/key retained in SUSPENDED" (connect first, then suspend).
  • connection_failures: RTN15g "no resume after connectionStateTtl" -> RTN14h "still attempts resume after the TTL", asserting every post-suspension reconnect carries resume=.
  • connection_recovery: RTN16g2 -> RTN16g3; the SUSPENDED case now expects a non-null recovery key.
  • channel_properties: RTL15b1 "channelSerial cleared on suspended" -> RTL15b2 "retained in suspended"; detach/failed cases relabelled.
  • channel_attach: RTL4j "ATTACH_RESUME set on reattach" -> "not set".
  • proxy/connection_resume: Test 22 RTN15g/g2 -> RTN14h; the post-TTL reconnect now asserts the resume param is present.
  • completion-status: matrix updated for RTN8d/RTN9d, RTN14h, RTN16g3, RTL15b2.

@SimonWoolf
SimonWoolf requested a review from ttypic July 23, 2026 18:07
ttypic
ttypic approved these changes Jul 24, 2026
View reviewed changes

@ttypic ttypic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@SimonWoolf
SimonWoolf force-pushed the uts-6.1.0-server-resumability branch from 6f8fd80 to 3406716 Compare July 24, 2026 15:28
@paddybyers

paddybyers commented Jul 27, 2026

Copy link
Copy Markdown
Member

@ttypic how are we tracking now the spec version that each library implements (especially those that have UTS-based test suites)?

AndyTWF added a commit to ably/ably-dotnet that referenced this pull request Sep 3, 2026
@AndyTWF @claude
Return a recovery key while suspended
8ba9920 
RTN16g3 - implemented. Replaces RTN16g2, which listed SUSPENDED among the states where
createRecoveryKey returns null. RTN8d and RTN9d now keep the connectionKey through
SUSPENDED because RTN14h always attempts a resume, so the connection is still recoverable
there and the key has to be available to hand to another client. Withholding it left the
SDK holding a usable recovery key it would not surface, in the one prolonged-outage state
where handing recovery over is most useful.

RTN16g3 is not yet in the published specification - ably/specification#511 adds it and
tombstones RTN16g2. Implemented ahead of that merging because it is the direct consequence
of RTN14h in the previous commit, and shipping the two apart would mean two behaviour
changes for callers instead of one. ably-js already behaves this way, from 2.27.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@AndyTWF AndyTWF mentioned this pull request Sep 3, 2026
Open
@AndyTWF

AndyTWF commented Sep 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

(RTN27d) SUSPENDED - a state where the library is not connected to the server and is not actively attempting to become connected, but where a reconnect attempt is scheduled in the future after the TO3l2 suspendedRetryTimeout elapses, and where next connect attempt is a clean connection (not a resume attempt).

Feels like RTN27d could be in the scope of this PR as I believe it's a relic of the pre-RTN14h days, as theoretically an SDK could become "suspended" but the server may well still have the information it needs to resume when it comes back? That is also the basis on which ably-js implemented it.

AndyTWF added a commit to ably/ably-dotnet that referenced this pull request Sep 3, 2026
@AndyTWF @claude
Return a recovery key while suspended
ed44219 
RTN16g3 - implemented. Replaces RTN16g2, which listed SUSPENDED among the states where
createRecoveryKey returns null. RTN8d and RTN9d now keep the connectionKey through
SUSPENDED because RTN14h always attempts a resume, so the connection is still recoverable
there and the key has to be available to hand to another client. Withholding it left the
SDK holding a usable recovery key it would not surface, in the one prolonged-outage state
where handing recovery over is most useful.

RTN16i - fixed alongside it. GetChannelSerials filtered on ChannelState.Attached, and RTL3c
puts every channel into SUSPENDED when the connection suspends, so the key would have gone
out with no channelSerials at all - connection continuity without message continuity, and
nothing to tell the caller. Gated on the serial instead, as ably-js does; RTL15b2 already
keeps it through SUSPENDED.

RTN16g3 is not yet in the published specification - ably/specification#511 adds it and
tombstones RTN16g2. Implemented ahead of that merging because it is the direct consequence
of RTN14h in the previous commit, and shipping the two apart would mean two behaviour
changes for callers instead of one. ably-js already behaves this way, from 2.27.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AndyTWF added a commit to ably/ably-dotnet that referenced this pull request Sep 3, 2026
@AndyTWF @claude
Return a recovery key while suspended
40f5e1e 
RTN16g3 - implemented. Replaces RTN16g2, which listed SUSPENDED among the states where
createRecoveryKey returns null. RTN8d and RTN9d now keep the connectionKey through
SUSPENDED because RTN14h always attempts a resume, so the connection is still recoverable
there and the key has to be available to hand to another client. Withholding it left the
SDK holding a usable recovery key it would not surface, in the one prolonged-outage state
where handing recovery over is most useful.

RTN16i - fixed alongside it. GetChannelSerials filtered on ChannelState.Attached, and RTL3c
puts every channel into SUSPENDED when the connection suspends, so the key would have gone
out with no channelSerials at all - connection continuity without message continuity, and
nothing to tell the caller. Gated on the serial instead, as ably-js does; RTL15b2 already
keeps it through SUSPENDED.

RTN16g3 is not yet in the published specification - ably/specification#511 adds it and
tombstones RTN16g2. Implemented ahead of that merging because it is the direct consequence
of RTN14h in the previous commit, and shipping the two apart would mean two behaviour
changes for callers instead of one. ably-js already behaves this way, from 2.27.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@SimonWoolf @claude
Sync UTS specs with 6.1.0 server-side resumability; add RTN16g3
d0d1c02 
Spec PR #488 ("Move resumability decisions from the client to the
server", specification version 6.1.0) updated features.md and
api-docstrings.md but did not update the UTS test-spec sources or address
createRecoveryKey's behaviour in SUSPENDED. This brings both in line.

features.md:
- RTN16g2 is replaced by RTN16g3: createRecoveryKey() no longer returns
  Null in SUSPENDED. Since the client now retains its connectionKey and
  always attempts to resume (RTN14h), the connection remains recoverable
  while suspended. (RTN16g2 as written still listed SUSPENDED, which
  contradicts RTN8d/RTN9d retaining the key.)
- tweak wording of RTN27d (which is one of those "spec points" that shouldn't
  really be a spec point because it's kindof flavour-text for an enum member
  rather than specifying behaviour, so I don't think it needs a break)

UTS sources:
- connection_id_key: RTN8c/RTN9c "id/key null in SUSPENDED" -> RTN8d/RTN9d
  "id/key retained in SUSPENDED" (connect first, then suspend).
- connection_failures: RTN15g "no resume after connectionStateTtl"
  -> RTN14h "still attempts resume after the TTL", asserting every
  post-suspension reconnect carries resume=<connectionKey>.
- connection_recovery: RTN16g2 -> RTN16g3; the SUSPENDED case now expects
  a non-null recovery key.
- channel_properties: RTL15b1 "channelSerial cleared on suspended"
  -> RTL15b2 "retained in suspended"; detach/failed cases relabelled.
- channel_attach: RTL4j "ATTACH_RESUME set on reattach" -> "not set".
- proxy/connection_resume: Test 22 RTN15g/g2 -> RTN14h; the post-TTL
  reconnect now asserts the resume param is present.
- completion-status: matrix updated for RTN8d/RTN9d, RTN14h, RTN16g3,
  RTL15b2.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@SimonWoolf
SimonWoolf force-pushed the uts-6.1.0-server-resumability branch from 3406716 to d0d1c02 Compare September 3, 2026 21:28
@SimonWoolf

SimonWoolf commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

oh, I forgot to merge this, sorry

Feels like RTN27d could be in the scope of this PR

Good point thx, I'll trim off the last clause. (it's one of those "spec points" that shouldn't really be a spec point because it's kindof flavour-text for an enum member rather than specifying behaviour, so I don't think it needs a break)

@SimonWoolf
SimonWoolf merged commit ba10845 into main Sep 3, 2026
2 checks passed
@SimonWoolf
SimonWoolf deleted the uts-6.1.0-server-resumability branch September 3, 2026 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ttypic ttypic ttypic approved these changes

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@SimonWoolf @paddybyers @AndyTWF @ttypic